Each separate file is known as a game module or just module. A module has a name, displayed name, an advertising-style blurb, a version, and designer notes.
This is an example of an elaborately-declared game module with no actual content:
(game-module "foobar" (title "Foo of Bar") (blurb "An exciting game with lots of cliffhanging suspense") (version "1.3") (program-version (>= "7.0.3")) ;; other properties? (complete-game true) ) ;;; contents here (game-module (notes ( "This is just a sample game." "" "It's not really as interesting as the blurb makes out." ))) (game-module (design-notes ( "This is commentary addressed to other designers." "Also a good place to mention things to work on." )))
The notes and design-notes could have been supplied with
the first game-module declaration, but in practice, putting the
player and designer notes at the end of the file keeps them out of the
way. You can supply any number of game-module declarations in a
file. Only the first need include a name.
The game module format is only loosely structured. In general, anything that you might want to reuse or combine in different ways should be a separate module. Good candidates include text generators and maps of real terrain. Unfortunately, they don't always mix-and-match as well as you might like!
The following are the generally preferred module names:
Terrain-only modules should be named t-xxx.
Lists of units should be named u-xxx or ob-xxx
(for "order of battle").
Name generators should be name ng-xxx.
When supplying a year in the module name, use four digits, unless the rest of the name makes the century clear (WWII scenarios are pretty much guaranteed to be in the 20th century!).